QRZ! Ham Radio 3/QRZ Ham Radio Callsign Database - Volume 3.iso/digests/tcp/930055.txt

Internet Message Format | 1994-06-04 | 14KB

Date: Sat, 27 Feb 93 04:30:13 PST
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V93 #55
To: tcp-group-digest


TCP-Group Digest            Sat, 27 Feb 93       Volume 93 : Issue   55

Today's Topics:
                   GRI 2.0m and multiple FTP drives
                            Long Messages
                          Mind your layers!
                           Open Squelch SCC
                  physical layer and FEC engineering
                               Protocls
     Use of fixed-length data fields considered harmful. (2 msgs)

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 26 Feb 1993 23:36:08 +0800
From: RON MURRAY <[e-mail]>
Subject: GRI 2.0m and multiple FTP drives
To: [e-mail]

   I implemented Jerzy's code into GRI 2.0m this evening, and all seems to
be going well (so far, anyway). I will test it over the next few days.

   One problem that I have discovered so far is that strange things happen
if you try and CD to a floppy drive and there is no disk in the drive (yeah,
I know, but the average user will try *anything* ....). Currently it seems
to fill the monitor screen with junk for some reason; it does, however,
recover ok.

   This seems to be a problem with the Borland library, or even lower: the
NOS code is quite simple at this point. I attempted to add similar code for the
local CD command (I have two hard drives; it seems silly to be restricted
to one when using NOS), with much the same result when I attempted a DIR
or CD to a drive with no floppy inserted. I'll persevere with it, although
I suppose I'd better make sure it doesn't interfere with the TMPNAM stuff!
Apart from the above effect, however, it does seem to work (so far...).

   It would probably also be a good idea to allow access to other drives
from the mailbox W, D and U commands. The only problem I see with this is
the mailbox permissions: either these will have to be repeated for each drive
like:

fred blahblah c:files 127 d:/morefile 127 a: 127 b: 127

   which is messy, especially if you want to restrict writing to floppies
(it takes time to calculate the permission values), or (much better, IMHO)
something like:

fred blahblah c:/files 127 d:/morefile 3 a: 1 b: 1

   and take the mailbox permissions from the first permissions field.

   It's quite possible that the code already does this; I must admit that I
haven't checked.

 .....Ron

                                 ***
 Ron Murray
 Internet: [e-mail]
   "Women are like elephants to me -- I like to look at 'em, but I wouldn't
       want to own one."     -- W. C. Fields

------------------------------

Date: Fri, 26 Feb 93 18:48:04 CST
From: [e-mail]
Subject: Long Messages
To: [e-mail]

C'mon, people....This has little relavency to the purpose of tcp-group.  Use
whatever compression technique is appropriate for the platform(s) the file
is for, make it available for ftp somewhere, and send a message informing
people where the file is.  Let's not turn tcp-group into a "this compression
technique is better than that one!" jihad.

Back to networking...what tcp-group is for.
----
Jim Henderson, KD4LDO/W0 [e-mail] [44.94.249.38] on 144.99 MHz
Crystal, MN                     Internet:  [e-mail]
CIS:  71321,1461                Alt. Internet:  [e-mail]

"Don't ask me how it works or I'll start to whimper!" - Arthur Dent

------------------------------

Date: Fri, 26 Feb 1993 14:10:06 -0800 (PST)
From: Bruce Perens <[e-mail]>
Subject: Mind your layers!
To: Mike Westerhof DSEM Northern IL <[e-mail]>

On Fri, 26 Feb 1993, Mike Westerhof DSEM Northern IL wrote:
> As we begin using variable length everythings, we make error-checking much
> more difficult -- a bogus frame might result in a 4096 byte destination
> address -- difficult to deal with at best!
> I suggest that we CRC check or at least checksum the header.

What you missed is that we are discussing the Link-layer packet.
The error checking goes in the Media Access Control Layer, which is
below the Link Access Layer. When Phil and Glen talk about FEC, they are
discussing MAC-Layer issues. When Warren and I discuss addresses, we are
talking about the Link-layer.

Here's the protocol stack (building on the way Warren specified it),
which is based on the well-known ISO model of networking:

Transaction Control Protocol (TCP): A reliable sequenced packet stream
service. Client of IP.

Internet Protocol (IP): A reliable unsequenced datagram service. Client
of the Link Layer.

The Link Layer: Provides an unreliable packet service between two
stations. Is a client of the Medium Access Control layer.

Medium Access Control Layers: Error correction belongs here. Is a client
of the physical layer. This is where your checksum, etc., belongs.

Physical Layer: The actual hardware.



     Bruce

------------------------------

Date: Fri, 26 Feb 93 17:19:56 GMT
From: [e-mail] (Adrian Godwin)
Subject: Open Squelch SCC
To: [e-mail]

Barry VE3JF wrote:
>               How about getting one of those TAPR 'DCD upgrade' kits
> with the built-in state machine DCD, and marrying it up to the SCC card?
> Not the cheapest or most elegant solution, but it should work...

I can't remember if the recovered clock is available on the 8530 (I think it
might be a configuration option for the clock pins, but I don't have the
book to hand), but if it is, a simpler solution than a second DPLL may be
possible.

A PLL is in lock when there's a fixed phase relationship between clock and
data (that's obvious, right?). If you can detect this, you can detect
DCD : on a Hitachi 64180S (which provides a recovered clock output having
a fixed phase shift from the data edges), this detector is just a D-type
flipflop with received data on the clock input and recovered clock on the
D input.

When the loop's in lock, the D-type output is stable with a value that
depends on the phase difference between the recovered clock and the data :
when not in lock, it jitters madly. It can be filtered to generate DCD
just like the TAPR DPLL lock output.

I used a spare timer-counter input to count edges on the D-type output,
and avoided any need for an analogue filter at all (the counter's
preloaded with a constant that defines the sensitivity - if it doesn't
overflow within a fixed time period, the loop must be locked).

-adrian

------------------------------

Date: Fri, 26 Feb 93 16:32 CST
From: Jay Maynard                          <[e-mail]>
Subject: physical layer and FEC engineering
To: [e-mail](k1io, FN42jk)

Once again, I feel compelled to speak up in defense of folks who can't
afford to dedicate high-powered computer hardware to packet radio...
(No, Fred, I'm not picking on you specifically... :-)

Fred Goldstein, K1IO, writes:
> Simple convolutional coding isn't very CPU-intensive.  I don't
> know the procedures myself, but I'm sure it can be done on a
> 386 at packet radio speeds with no great effort.

Here we go again, with the $2500 TNC. (The price has dropped since I
complained about the $5000 TNC a while back.) While I have a 386DX-25
dedicated to packet radio, I'm decidedly in the minority. If I had
just one computer, it'd either be too low-powered to do the fancy schemes
proposed or would be doing other things besides packet. That computer
would have better things to do besides fold, spindle, mutilate, and
stuff bits. Is this the kind of thing that can be offloaded to TNC-class
hardware? How about a TNC3 design, with not a lot of hardware around
an NEC V25 (neat little 8086-class micro we're building repeater
controllers with)?

We're not going to get anywhere at all if we keep insisting on doing
things that require computers the class of small DP centers to do stuff
with; we're artificially limiting our customer base for little good
reason.

...Jay, K5ZC

------------------------------

Date: Fri, 26 Feb 1993 12:50:33 -0800 (PST)
From: Bruce Perens <[e-mail]>
Subject: Protocls
To: Alan Cox <[e-mail]>

On Thu, 25 Feb 1993, Alan Cox wrote:
> Since bandwidth is so expensive and tx/rx swithcing causes a lot of the
> packet losses, maybe the protocol should allow multiple messages to
> different destinations with one source header containing all the
> constant information followed by a set of blocks containing destination
> address and data areas.

Let's discuss this seperately for each layer:

It's easy to send more than one physical-layer packet in a "batch" once
you've started transmitting, and my TNC does this whether I want it to
or not. The redundant things that you could get rid of at the physical
layer would be any time spent contending for the channel, the transmit
delay, and the synchronization sequence that the transport would need to
establish the clock when it started transmitting, since these need happen
only once when several physical-layer packets are sent together.

The Medium Access Control layer could have the capability to concatenate
several small Link-layer packets in a single MAC-layer packet. Of
course, such concentration reduces reliability since you could lose a
lot of packets instead of just one when the MAC-layer has an error that
it can't recover from. This depends on your form of error checking. For
FEC, this might be a big win. If you implement data-compression at the
MAC layer, and do FEC on compressed data, it could be a tremendous win.

At the Link Access Layer, you suggest that the source address could be
redundant. You assume that the source address is the same for each
packet - this may not be true, as in the case where the same station
responds to "KD6OTD-1" and "KD6OTD-2". I would prefer not to concentrate
source addresses at this layer, but if you used a data-compression
scheme at the MAC layer you could get the same effect.

One place where it is important to put lots of information for different
connections in one transmission is the case of terminal service. Someone
mentioned "echo minigrams" a few days ago. In the case of the Telnet
service with remote echo, you'd get this kind of thing, where a packet
would contain only one character of data: the echo of your last
keystroke. If you have one server that transmits a lot of these onto a
CSMA/CD network, it is generally best for that server to concatenate all
of the minigrams into one transmission. I've worked on a system where
echo minigrams were saved up, and transmitted in a batch every tenth of
a second. That worked very well - I would not notice the delay on a CRT
terminal, but I would notice it on a teletype, only because I could
_hear_ the delay. I don't know what layer concentrated the minigrams.

     Bruce

------------------------------

Date: Fri, 26 Feb 93 09:32:37 CST
From: [e-mail] (Mike Westerhof DSEM Northern IL)
Subject: Use of fixed-length data fields considered harmful.
To: [e-mail]

As we begin using variable length everythings, we make error-checking much
more difficult -- a bogus frame might result in a 4096 byte destination
address -- difficult to deal with at best!

I suggest that we CRC check or at least checksum the header.

------------------------------

Date: Fri, 26 Feb 1993 11:49:23 -0800 (PST)
From: Bruce Perens <[e-mail]>
Subject: Use of fixed-length data fields considered harmful.
To: Warren Toomey <[e-mail]>

> Ok, but don't have a separate field for address type, just use the first
> address octet as address type.
Fine with me!

Thus, we have the basic form of our packet as submitted by Warren:

Protocol   2 Octets
Destination address length: 1 Octet.
Host address length:  1 Octet
Data length:   2 Octets
Destination address:  0-255 Octets
Host address:   0-255 Octets
Pad:    0-3 Octets to align data to quadword.
Data:    0-65535 Octets.

Before anyone objects, the maximum length of the packet, and thus the
maximum length of the data, should be defined by the media access layer.
Thus, most media access layers won't allow you 65535 octets of data.

Now, we should propose a straw-man set of addressing forms. Of course,
not all stations will parse all address forms - many may only elect to
parse only one form. The ones I would start with are:

A zero-length destination address means "broadcast".

Type 0: An amateur radio callsign in ASCII (_not_ shifted as in AX.25).
 The callsign may optionally be followed by an ASCII hyphen,
 and an ASCII field indicating the substation. For example,
 "KD6OTD", "KD6OTD-1", and "KD6OTD-mobile1" would be legal
 values for a type-0 address. Do we want case-significance for
 ASCII?

Type 1: Same as above, but in a wide character set like UNICODE, for
 people who like non-Latin alphabets.

Type 2: A hierarchical address. Someone care to design one?

Type 225-255: For experimental use.

I would assume that IP addresses belong in the data field, but you
might wish to correct me.
     Bruce

------------------------------

Date: (null)
From: (null)
Protocol - 2 octets
Src addrlen - 2 octets
Dest addrlen - 2 octets
Data length - 2 octets
Header CRC - 2 octets

Src addr - n octets
Dest addr - m octets

Data  - x octets

Mike

------------------------------

End of TCP-Group Digest V93 #55
******************************
******************************